home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5491 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: news.halcyon.com!usenet
  2. From: normanb@halcyon.com (Norm Bryar)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Painted into a corner?
  5. Date: Sun, 04 Feb 1996 23:16:13 GMT
  6. Organization: Northwest Nexus Inc.
  7. Message-ID: <4f3en2$7jf@news.halcyon.com>
  8. References: <d5e2.smail.smayo@tiac.net>
  9. NNTP-Posting-Host: blv-pm11-ip19.halcyon.com
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. smayo@tiac.net (Scott Mayo) wrote:
  13.  
  14. >I've stumbled into an awkward case ...
  15.  
  16. >I have a class, X, which is never going to be instantiated, but subclasses derived
  17. >from it will be.  I have another class, Y, which might be instantiated someday,
  18. >though at the moment it exists only to support the subclasses Y1, Y2, and Y3.
  19.  
  20. >I need to create 3 new classes, X1, X2, and X3, which inherit as follows
  21. >X1: X and Y1
  22. >X2: X and Y2
  23. >X3: X and Y3
  24. >X4: X
  25.  
  26. >...I always need to manipulate instances of
  27. >Xn through pointers to X, and trust to virtual functions
  28. >to get the properly X1ish, X2ish and X3ish behaviour I need as regards
  29. >the behaviour of the Yish parts. X4 is willing to support dummy functions
  30. >so that it looks Yish as well; I'd rather it didn't inherit Y directly
  31. >as that would make it pointlessly bulky.
  32.  
  33. >The problem, which the experienced folk here probably see already, is that
  34. >if I create X *x, any time I try to do something like x->member_of_y(),
  35. >I get told that member_of_y() isn't part of X. ...
  36.  
  37. >The closest I've come to a workaround is to create, in X,
  38. >virtual member_of_y(), and then in each of X1...
  39.  
  40. >...
  41.  
  42. This doesn't sound quite right.  Putting do-nothing member_of_y()
  43. methods in X because clients of X expect some of Y's methods just
  44. seems to imply you could do better with a different hierarchy, perhaps
  45. another abstract class, XwithY.   Now, why is it so distateful to
  46. derive X4 from both X and Y?
  47.  
  48. If some clients of X expect to find Y methods, then those clients
  49. might do better to accept a Y reference or some new XwithY.
  50.  
  51. Clients can also dynamic_cast<Y *>(pX) if your compiler supports
  52. run-time type information (RTTI).  The cast would return null for X
  53. pointers really pointing to X4s, and would return a Y ptr otherwise.
  54.  
  55. My two cents.
  56.  
  57.                     --Norm
  58.  
  59.  
  60.